1. Field of the Invention
The present invention relates to an information processing technique for executing print processing using a plurality of different graphics engines.
2. Description of the Related Art
An arrangement shown in FIG. 1 is generally used when printing image and text data from an application on a host computer 3000 using a printer 1500. An application 101 passes drawing data to a graphics engine 103, which processes the drawing data and passes it to a printer driver 104. The printer driver 104 generates print data (generally, PDL, Page Description Language data) for the printer 1500, and stores the print data in a spooler 105. Then, the print data is sent to the printer 1500. In particular, the graphics engine 103 executes processing of the drawing data (e.g., conversion of the resolution of drawing data generated by the application 101, simulation processing in correspondence with the processing capacity of the printer driver 104, and the like). Thus, the application 101 and printer driver 104 can operate independently. This graphics engine 103 is normally provided as a part of an OS (Operating System) 102.
Furthermore, the number of graphics engines is not limited to one, and an arrangement that includes two or more graphics engines is available. For example, in 2005 Microsoft Corporation organized the hardware engineering conference “WinHEC 2005” in Seattle, U.S.A. Daniel Emerson, “Advances in Windows Printing”, WinHEC 2005 Conference, April 2005, at which Microsoft announced its latest OS (Windows® Vista) adopts an arrangement in which two graphics engines coexist, as shown in FIG. 2.
Conventionally, an application (Win32 application) 201 that uses an API (Application Program Interface) (i.e., Win32 API) leverages a graphics engine 202 called a GDI (Graphic Device Interface). A printer driver (GDI printer driver) 203 called from the GDI 202 generates print data based on drawing data. This print processing flow will be referred to as a GDI print path hereinafter.
Windows® Vista adds a new print processing flow called an XPS (XML Paper Specification) print path in addition to the conventional GDI print path. The XPS print path leverages a graphics engine 212 called a WPF (Windows® Presentation Foundation) from an application (WinFx application) 211 that uses a WinFx API. A printer driver (XPS printer driver) 213 converts drawing data in an XPS (XML Paper Specification) format into print data.
Furthermore, graphics engines such as the GDI 202 and WPF 212 can cooperate with each other. With this cooperation, the Win32 application 201 can pass drawing data to the XPS printer driver 213, and the WinFx application 211 can pass drawing data to the GDI printer driver 203.
FIG. 3 shows cooperation between the two graphics engines in Windows® Vista. A print processing flow (1) indicates the conventional GDI print path. The GDI 202 stores drawing data passed from the Win32 application 201 as an EMS spool file 301 having an EMF (Enhanced Metafile) format. After that, the GDI printer driver 203 converts the stored drawing data into print data.
A print processing flow (4) indicates the XPS print path added in Windows® Vista. The WPF 212 stores drawing data passed from the WinFx application 211 as an XPS spool file 311. After that, the XPS printer driver 213 converts the stored drawing data into print data. In this way, the print processing flows (1) and (4) will be referred to as straight print paths hereinafter.
A print processing flow (3) is used on printing data from the WinFx application 211 by the GDI printer driver 203. An XPS→CDI conversion module 312 converts drawing data passed from the WinFx application 211 into that of the EMF format via the WPF 212, and stores the converted data as an EMF spool file 301. After that, the GDI printer driver 203 converts the stored data into print data.
A print processing flow (2) is used on printing data from the Win32 application 201 by the XPS printer driver 213. A GDI→XPS conversion module 302 converts drawing data passed from the Win32 application 201 into that of the XPS format via the CDI 202, and stores it as an XPS spool file 311. After that, the XPS printer driver 213 converts the stored data into print data. In this way, the print processing flows (2) and (3) will be referred to as cross print paths hereinafter.
As described above, in Windows® Vista, four print processing flows are prepared. A printer can cope with print processing from both a Win32 application and a WinFx application by preparing either one of the GDI printer driver 203 or XPS printer driver 213.
The above prior art is described in, for example, Japanese Patent Laid-Open No. 2001-154821.
However, since the XPS and EMF formats are different, the print processing flows that require conversion of drawing data like the print processing flows (2) and (3) present problems for print quality, functionality, and print speed.
Regarding print quality problems, for example, in the print processing flow (2), the XPS format does not support drawing data including logical operations such as ROP (raster operation processing) operations, which are supported by the EMF format. For this reason, depending on the specification determined by Microsoft Corporation, logical operation information may be excluded from such drawing data upon conversion by the GDI→XPS conversion module 302. In this case, since drawing data from which the logical operation information is discarded is passed to the XPS printer driver 312, the XPS printer driver 312 cannot generate the output result that the Win32 application 201 intended.
Conversely, in the print processing flow (3), the EMF format does not support the advanced graphics drawing data supported by the XPS format. For this reason, local bitmap conversion called “Flattering” is applied to such drawing data upon conversion by the XPS→GDI conversion module 312. In this case, since graphics data is converted into bitmap data, the GDI printer driver 203 cannot discriminate original object attributes, and cannot generate an optimal output result. For example, upon executing N-page printing by the printer driver, since bitmap data are laid out in a reduced size, the image quality deteriorates compared to the case wherein graphics drawing objects are drawn in a reduced size.
As for printing functionality, for example, in the print processing flow (3), the EMF format does not support electronic signature information supported by the XPS format. Further, the XPS format does not support processing which directly sends information from an application to the GDI printer driver 203, however, this is supported by the EMF format in the print processing flow (2). For this reason, even when an application uses functions which can be supported by print processing flows (1) and (4), such functions cannot be implemented by print processing flows (2) and (3).
Note that a print mode via the straight print path by print processing systems (to be referred to as “print processing flows” hereinafter) (1) and (4) will be referred to as a native print mode hereinafter, and a printer driver using such a mode will be referred to as a native driver hereinafter. A print mode implemented via the cross print path using print processing flows (2) or (3) will be referred to as a non-native print mode, and a printer driver using such a mode will be referred to as a non-native driver hereinafter.
As for the print speed, since GDI→XPS conversion or XPS→GDI conversion occurs in the print processing flow (2) or (3), the print processing speed is reduced compared to the print processing flow (1) or (4).
For this reason, avoiding print processing flows (2) and (3) is desirable. However, even when both the XPS printer driver and GDI printer driver are registered for a single printer, the graphics engine in Windows® Vista does not dynamically switch the processing to preferentially select print processing flow (1) or (4). Furthermore, the user basically does not distinguish between Win32 and WinFx applications and does not recognize the four different types of print processing flows. For this reason, upon execution of print processing, it is difficult to avoid print processing flows (2) and (3), and it is also difficult to use the native driver as an optimal combination with the application.
It is an object of the present invention to provide an information processing technique that allows selection of a printer driver suited to an application in an arrangement in which a plurality of graphics engines exist together, and in which printer drivers of different graphics engines can be installed.